如果红帽软件终将改变，那么我们只能做到，不改变开源的初心
摘要：除了必要的商业产品，红帽软件不生产开源软件，它是开源软件的搬运工，向世界提供了一种构建开源软件的最优组合。红帽变更软件源策没有违背开源精神，符合 GPL 开源许可证要求。人们抱怨的是失去免费获取构建开源软件最优组合的「菜谱」，毕竟「巧妇难为无米之炊」。
6 月 21 日，红帽软件宣布将 CentOS Stream 的源码发布到 git.centos.org，而 Red Hat Enterprise Linux（简称 RHEL）的源代码则面向红帽软件订阅用户开放，订阅用户可以通过 Red Hat Customer Portal 访问，但是无法进行二次分发，红帽软件又变了。
人们的抱怨也来自于这种变化：抱怨红帽软件太过绝情，构建生态时「你好我好大家好」，但是只用了两年的时间，就完成了从操作系统到软件源的全面转变；抱怨红帽软件提供的开源软件最优组合「菜谱」即将消失，「巧妇难为无米之炊」。
我们应该如何看待这种变化？
首先，云计算时代，容器才是最值得关注的基础设施，CentOS 无法为红帽软件继续提供商业价值，无继续维护的必要。这不仅是基础设施载体的变化，而是整个协作方式的变化。红帽软件的 OpenShift 基于开源软件构建，但是面向社区和开发者免费提供的是二进制版本。它还是会使用开源软件、贡献开源软件，但是最终构建的产品将不再是开源软件。
CentOS 更新策略变更的这两年，是红帽软件给使用 CentOS 企业的一个缓冲期，红帽软件希望企业能够使用操作系统迁移工具，将业务从 CentOS 迁移到 RHEL 之上。salesforce 响应了这个号召，完成了 20 万套 CentOS 向 RHEL9 的迁移。这次软件源变更，可以看作红帽软件对使用CentOS 企业的最后通牒。
至于 CentOS 的未来，CentOS 在红帽软件没有未来，它只会被红帽软件废弃。容器时代，红帽软件希望用户的业务都是运行在 RHEL 之上，而不是CentOS 或者兼容 CentOS 的 Linux 之上。
CentOS 更新策略变更后，企业的选择无非就四种：使用 CentOS Stream、寻找兼容的 CentOS 代替品、购买 RHEL、购买其他企业级 Linux 发行版；RHEL 软件源获取策略变更后，企业的选择只有两种：购买 RHEL、购买其他企业级 Linux 发行版。考虑到红帽软件的生态粘性，多数企业应该会选择 RHEL。
这次红帽软件把 RHEL 源码缩小到了订阅用户范围，也就是企业用户。为什么？因为企业的需求更纯粹，它们需要的是一个开源的、稳定的企业级 Linux；需要的是一个软件、硬件生态丰富的企业级 Linux。这几句描述的就是 RHEL。至于RHEL源码是否可以获得，这是非订阅用户考虑的问题。后续的新硬件和软件如何适配？答案是只要 RHEL 的企业用户足够多，市场份额足够大，用户需求足够强烈，RHEL 的生态引力就能够驱使新的硬件和软件来适配 RHEL，而这些硬件和软件背后，还是企业，他们也可以成为 RHEL 的订阅用户，进而可以获得 RHEL 的源码。红帽软件用订阅用户获取源码这个思路，圈出来了一批核心的用户和开发者，这个群体的开发的软件和硬件，与 RHEL 原生适配，符合上文提到的「红帽软件希望用户的所有业务都是运行在 RHEL 之上」的这个目标，这将是红帽软件未来的商业模式。
其次，这种商业模式是否违反了 GPL 开源许可证的要求？答案是没有。这得益于红帽软件精巧的许可协议设计。首先，订阅用户获取源码符合开源软件「允许收取不超过软件成本的价格获取源代码」的要求，所以没有违反。其次，GPL 只规定源码要开放，对于开放的人群大小并没有规定，所以没有违反。那么订阅用户不允许二次分发代码是否违反了 GPL 开源许可证了吗？答案是没有。我看了一下红帽软件企业许可协议中的条款，大体意思是：红帽软件有权按照许可协议规定的相关要求，检查订阅用户是否合理使用 RHEL，如果出现不合规的情况，订阅用户要在15 个工作日内完成整改，否则会进行罚款，如果订阅用户的欠款超过了总欠款的 5%，红帽软件负责审查的费用就该订阅用户支付。这个合理使用指的是，不包含违反相关保密性的协议条款。两者结合一下，如果不合理使用，例如将源码二次发布，那么只需要向红帽软件交罚款就可以了，也是一种另类的「付费获取源码」的方式。
禁止分发源代码是写在许可协议中的，如果你分发了源代码，那你行使了GPL赋予你的权利，但是违反了许可协议的要求。你确实拿到了源码，分发了源码，而红帽软件也确实可以根据许可协议，停止对你提供订阅服务。这时候，你手里的代码，将会毫无价值。
最后，破解上游软件源变更风险最好的方式，就是敢于与 CentOS 不兼容，既要绕过红帽软件这个「捷径」，完全脱离红帽软件的构建的生态引力，社区或企业直接对接发布软件的根社区，又要学习红帽软件编写 spec 文件的经验，社区开发者自行编写 spec 文件，并完成后续的软件包构建，测试、发布、维护等环节，自行找出属于自己的开源软件最优组合「菜谱」。做好这件事儿并不简单，因为 CentOS 的软件包数量超 30000 个，软件包具有非常明显的「长尾效应」，需要开源社区拥有长远的战略眼光、较强的技术实力、众多的人力投入和雄厚的资金支撑。